I'd appreciate to have two PRs:

• one for the CPG changes (with it's own tests, so that we can see how it's supposed to work in general and not only in the specific python use-case)
• one making use of the first PR by implementing the Python stuff

Done. #1742

I get why you modify the scope of a Reference as this is how the Python front-end works. However, don't we need a scope modifier for the declaration (I get that this will be problematic with the Python "add declarations pass"?

The declaration's scope is not modified. Only the "lookup scope" of the symbol that you are trying to resolve in the current scope is modified (e.g., from the local to the global scope).

The trick is that the add-declaration-pass will then create the variable in the lookup-scope (if it does not exist). So if we have a global c and a c = 2 in the block, there will be a global lookup and if it fails, we will create the node in the global scope. I will improve this logic in this PR a little bit after #1742 is merged in.

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
76.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

Codecov Report

Attention: Patch coverage is 89.09091% with 6 lines in your changes missing coverage. Please review.

Project coverage is 74.94%. Comparing base (3e2db5c) to head (e33fa16).
Report is 1 commits behind head on main.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.